1. Field of the Invention
The present invention relates to systems and methods for the transfer of protected media assets, and in particular to a system and method for the interruptible transfer of protected media assets.
2. Description of the Related Art
It is often desirable for media content vendors to allow customers to play back copy-protected media assets on more than one device. For example, a consumer may have purchased a movie that is baselined for playback using a desktop computer or DVD player, but may later desire to play back the media content on another desktop computer, or a mobile device such as a laptop, tablet computer, or smartphone. FIG. 1 is a diagram depicting the transfer of a media asset from a source device 102 such as a DVD player or home computer to a sink device 104.
At the same time, the media content vendors typically desire to limit the number of usable (e.g. viewable) copies of the media asset at any given time. In other words, the goal is to transfer asset from a source to a sink without altering its status as copy protected. In this context, the term “copy protected” indicates that the asset is protected from being copied where “copied” means that two identical, usable assets are created from one usable asset. The modifier “usable” in the term “usable asset” indicates that the asset can be presented, played, decoded, streamed, transferred to another device, etc.
In order for a DRM to be able to provide dependable asset transfer (without the possibility for the creation of duplicate usable content) between two devices, a form of negotiation between the source device and the sink device after the content has been transferred is typically required. One such method for transferring one copy of a media content from a source device to a sink device is according to a basic protocol consisting of three phases: (1) authenticated key exchange (AKE), (2) transmit (T) and (3) commit (C). In this paradigm, the source and sink establish move key that is used to encrypt the media content before transmission, transmit the media content, and then commit the transfer. In the commit phase, the sink indicates to the source that it desires to mark its newly transferred content as “usable” so that it may be viewed on the sink device. The source device responds my marking it's version of the content as “unusable” and notifies the sink device that this has taken place. The sink device then alters the state of the newly transferred content to “usable” and notifies the source device. The source device acknowledges the sink device's indication that the content is usable on the sink device, and responds by marking its copy of the content as “unusable” or deletes it altogether. Using this paradigm, only one version of the content is usable at a time.
One example of this paradigm is the method of the Digital Transmission Content Protection-Internet Protocol (DTCP-IP) to transfer one copy of content from the source device to a sink device using a DTCP-IP “MOVE” instruction. A “MOVE” is the process by which a copy protected asset is transferred from a digital media source to a digital media sink device with DTCP-IP digital rights management (DRM). The MOVE protocol ensures that only one usable copy of a copy protected asset can be in existence at one time when in the act of sharing an asset between more than one device. DTCP-IP implements this negotiation as a “MOVE COMMITMENT”.
While this type of coordination between the source and the sink device is necessary to determine which device retains the usable copy of the asset, it does not come without detracting from real-world user experiences of the solutions which may employ asset transfer technology.
Two use cases for which MOVE transactions prove to be problematic. The first is “watch as you transfer” (WAYT) or “watch as you sync”. “Watch as you transfer” is a feature whereby the content is “used” (presented/displayed) by the sink device as the asset is transferred. But the asset cannot be made usable to the sink device until after all the content associated with the asset has been transferred to the sink device and the COMMITMENT phase is complete. So, the WAYT feature cannot be implemented with DTCP-IP or similar DRMs that use a “usability handoff” to conclude the asset transfer like DTCP-IP MOVE does with the COMMITMENT.
The second use case involves the ability to resume a previously interrupted MOVE based asset transfer. DTCP-IP MOVEs are bound to a unique “move key” (Kxm) which is used in crypto operations on the asset as it is pushed to and from the network medium. DTCP-IP requires that the move key expires if either the source or sink device detects itself being disconnected from the network. To exacerbate the issue with mobile clients, entering into the stand-by state can also cause Kxm to expire. Unfortunately, network disconnection and stand-by state transitions are common occurrences with mobile devices such as smartphones, tablets, and laptops, and can lead to many failed asset transfers. To resume these failed asset transfers, the sink device must establish a new Kxm and retransmit all content which was sent in the prior asset transfer attempt. This can be a highly inefficient (time incurred to retransfer) and a potentially costly way (if paying for bytes transferred (cellular)) to handle potentially large asset transfers.
What is needed is a system and method for transferring copy-protected media assets among devices without the foregoing problems. Such a system and method is described below.